Inter-hospital electronic medical record access authentication protocol based on blockchains

ABSTRACT

A method for inter-hospital identity authentication and electronic medical record transfer of patients is provided. Based on a blockchain technology, a patient achieves secure and efficient inter-hospital transfer authentication, and a new hospital accesses an electronic medical record with authorization of the patient, thus achieving reliable electronic medical record access controls. In each hospital, the patient, a medical server, and a doctor achieve efficient tripartite authentication and negotiation of session keys, and communicate based on the session keys. By introducing an elliptic curve to encrypt key parameters in an authentication process, a security of the entire authentication process is improved, and a computational pressure on a wireless device is reduced. In the authentication and the electronic medical record, the patient uses dynamic anonymity policies to protect privacy.

TECHNICAL FIELD

The disclosure relates to a field of information security technologies,in particular to an inter-hospital electronic medical record accessauthentication protocol based on blockchains.

BACKGROUND

Intelligent healthcare provides convenient and personalized services forpatients based on an advanced information technology and an internet ofmedical things (IoMT) technology. However, in practical applications,patients transfer authentication and electronic medical record accesscontrols among different hospitals are still difficult and cumbersome.The patient usually needs to re-register and authenticate whentransferring to another hospital, and a previous electronic medicalrecord is difficult to share, forming an information island, which is agreat waste of public resources.

Medical data mainly based on electronic medical records has always beenunder threats of attacks, and attackers use various attack methods tosteal medical data of patients from a medical system. Centralization ofthe medical system increases risks of data breaches when attacked.Digitization and informatization of the medical systems is an inevitabletrend of development, and ensuring an efficient identity transfer amonghospitals and secure access controls of transferred electronic medicalrecords is of great significance for the digitization of the medicalsystem and a privacy protection of the patients.

Compared to other encryption algorithms, elliptic curve cryptosystemsare particularly suitable for devices with limited computing and storageresources owning to their advantages such as short keys, high strength,fewer parameters, fast digital signatures, and small computational data.A blockchain technology has characteristics of a decentralization,non-tampering, and non-forgery, and using a blockchain for the storageand the access control of the electronic medical records can ensure asecurity of the electronic medical records.

SUMMARY

In order to solve problems existing in current medical scenes, thedisclosure proposes an inter-hospital electronic medical record accessauthentication method based on a blockchain. The method is applicable tointer-hospital authentication and inter-hospital medical record accesscontrols of patients in a medical system, and has characteristics ofanti-attack, tamper resistance of medical records, dynamic anonymity ofpatient identities, a privacy protection, and an access control ofinter-hospital medical records.

In order to achieve above purposes, the disclosure adopts aDiffie-Hellman key exchange (DHKE) and introduces elliptic curvecryptography to encrypt and protect key parameters in authenticationprocesses, meanwhile, adds a three factor authentication method toresist offline password guessing attacks and session key disclosureattacks, thus improving a security of an entire authentication process.Simultaneously a blockchain technology is used to achieve a sharing ofelectronic medical records and authorized secure access controls.

An inter-hospital electronic medical record access authentication methodbased on a blockchain includes the following steps:

-   -   S1: a medical server is initialized;    -   S2: a patient and a doctor submit registration requests to the        medical server through a user device of the patient and a device        of the doctor, after the medical server verifies legality of        identities of the patient and the doctor, registration messages        are fed back to the user device of the patient and the device of        the doctor, and the registration messages of the patient and the        doctor are stored on a smart card of the patient and the device        of the doctor respectively;    -   S3: the user device of the patient submits an initialize        authentication request to the medical server;    -   S4: the doctor performs a diagnosis on the patient when the        patient, the medical server, and the doctor complete initialize        authentication and negotiate session keys for communications,        and the medical server uploads an electronic medical record of        the patient to the blockchain;    -   S5: the patient submits a transfer authentication request to a        medical server of another hospital where the patient is located        when the patient is transferred to the another hospital; and    -   S6: in the another hospital, after the patient, a medical        server, and a doctor complete transfer authentication, negotiate        and verify session keys for communications, the patient        authorizes the medical server to access the electronic medical        record of the patient, and the doctor performs a diagnosis on        the patient, the medical server uploads another electronic        medical record of the patient to the blockchain.

In an embodiment, the medical server is initialized in the S1 asfollows: the medical server selects an E(GF_(q)) function of an ellipticcurve and selects a base point P on the elliptic curve; then selects aserver key k_(MSj) and stores the server key k_(MSj) secretly in themedical server, and the medical server calculates a public key PK_(MSj)through the E(GF_(q)) function of the elliptic curve, finally exposesparameters {E(GF_(q)),P,PK_(MSj)}. In an embodiment, the S2 includes thesteps as follows:

-   -   S2.1: the patient inputs an identity ID_(i), a password PW_(i)        and biological message bio_(i) into the user device; and the        user device sends the identity ID_(i) to the medical server        through a secure channel;    -   S2.2: after receiving and verifying legality of the identity        ID_(i) of the patient, the medical server calculates a secret        value b_(i) between the patient and the medical server, and        sends the registration message of the patient to the user device        through a secure channel, and stores the registration message of        the patient in the smart card;    -   S2.3: the doctor inputs an identity DID_(n), a password PW_(n),        and biological message bio_(n) into the device, and the device        sends the identity DID_(n) to the medical server through a        secure channel; and    -   S2.4: after receiving and verifying legality of the identity        DID_(n) , of the doctor, the medical server calculates a secret        value b_(n) between the doctor and the medical server, and sends        the registration message of the doctor to the device of the        doctor through a secure channel, and store the registration        message of the doctor in the device of the doctor.

In an embodiment, the initialize authentication in the S4 is based onbidirectional authentication and key negotiation and verification amongthe smart card and the user device of the patient, the medical serverand the device of the doctor; and uploading the electronic medicalrecord of the patient in the S4 is based on a mutual confirmation amongthe smart card and the user device of the patient, the medical serverand the device of the doctor, and the electronic medical record isuploaded to the blockchain by the medical server.

In an embodiment, steps of the initialize authentication, the keynegotiation and verification, and uploading the electronic medicalrecord of the patient are as following:

-   -   S4.1: the patient inserts the smart card into the user device,        and after passing identity authentication, the user device        generates a current timestamp T₁ through the registration        message in the smart card, calculates verification parameters,        and sends a message MES₁ ^(j) to the medical server;    -   S4.2: after receiving the message MES₁ ^(j), the medical server        verifies legality of the timestamp T₁ and the validation        parameters in the message MES₁ ^(j); the bidirectional        authentication is terminated when the timestamp T₁ and the        validation parameters are not legal, or authentication from the        smart card of the patient to the medical server is successful        when the timestamp T₁ and the validation parameters are legal;    -   S4.3: after the authentication from the smart card of the        patient to the medical server is successful, the medical server        generates a temporary identity TID_(i) of the patient and a        current timestamp T₂, calculates verification parameters, and        sends a message MES₂ ^(j) to the device of the doctor;    -   S4.4: the device of the doctor receives the message MES₂ ^(j)        and verifies legality of the timestamp T₂ and the validation        parameters in the message MES₂ ^(j) ; the bidirectional        authentication is terminated when the timestamp T₂ and the        validation parameters are not legal, or authentication from the        medical server to the device of the doctor is successful when        the timestamp T₂ and the validation parameters are legal;    -   S4.5: after the authentication from the medical server to the        device of the doctor is successful, the device of the doctor        generates a current timestamp T₃, a session key SK_(nj) used for        communicating with the medical server and a session key SK_(in)        used for communicating with the patient, calculates validation        parameters, and sends a message MES₃ ^(j); to the medical        server;    -   S4.6: after receiving the message MES₃ ^(j), the medical server        verifies legality of the timestamp T₃ and the validation        parameters in the message MES₃ ^(j); the bidirectional        authentication is terminated when the timestamp T₃ and the        validation parameters are not legal, or authentication from the        device of the doctor to the medical server is successful when        the timestamp T₃ and the validation parameters are legal;    -   S4.7: after the authentication from the device of the doctor to        the medical server is successful, the medical server generates a        current timestamp T₄, a session key SK_(nj)′ used for        communicating with the device of the doctor and a session key        SK_(ij) used for communicating with the user device of the        patient, calculates verification parameters, and sends a message        MES₄ ^(j) to the user device of the patient;    -   S4.8: after receiving the message MES₄ ^(j), the user device of        the patient verifies legality of the timestamp T₄ and the        validation parameters in the message MES₄ ^(j); the        bidirectional authentication is terminated when the timestamp T₄        and the validation parameters are not legal, or the user device        calculates and verifies a session key SK_(in)′ used for        communicating with the doctor and a session key SK_(ij)′ used        for communicating with the medical server when the timestamp T₄        and the validation parameters are legal; and the smart card and        the user device of the patient, the medical server and the        device of the doctor successfully negotiate the session keys        with each other when the verification of the session key SK_(in)        and the session key SK_(ij) is successful;    -   S4.9: after the patient and the doctor communicates with each        other by using the session key SK_(in), the doctor performs a        diagnosis Dia_(n) on the patient, the device of the doctor        generates a current timestamp T₆, calculates verification        parameters, and sends message MES₅ ^(j) to the medical server;    -   S4.10: after receiving the message MES₅ ^(j), the medical server        verifies legality of the timestamp T₆ and the validation        parameters in the message MES₅ ^(j); the bidirectional        authentication is terminated when the timestamp T₆ and the        validation parameters are not legal, or a source of a diagnostic        result is reliable and verification of the medical server is        successful when the timestamp T₆ and the validation parameters        are legal;    -   S4.11: after the medical server verifies legality of the        diagnosis result, the medical server generates a current        timestamp T₇ and the electronic medical record of the patient,        calculates validation parameters, uploads the electronic medical        record to the blockchain, and sends a message MES₆ ^(j) to the        user device of the patient; and    -   S4.12: after receiving the message MES₆ ^(j), the user device of        the patient verifies legality of the timestamp T₇ and the        validation parameters in the message MES₆ ^(j); the        bidirectional authentication is terminated when the timestamp T₇        and the validation parameters are not legal, or the electronic        medical record is reliable and contents of the electronic        medical record is held accountable when the timestamp T₇ and the        validation parameters are legal.

In an embodiment, the transfer authentication in the S6 is based onbidirectional authentication and key negotiation and verification amongthe smart card and user device of the patient, the medical server and adevice of the doctor, and uploading the new electronic medical record inthe S6 is based on mutual confirmation among the smart card and userdevice of the patient, the medical server and a device of the doctor,and the new electronic medical record is uploaded to the blockchain bythe medical server.

In an embodiment, steps of the transfer authentication, the keynegotiation and verification, and uploading the electronic medicalrecord are as follows:

-   -   S6.1: the patient inserts the smart card into the user device,        and after passing identity authentication, the user device        generates a current timestamp T₈ through the registration        message in the smart card, calculates verification parameters,        and sends a message MES₁ ^(x) to the medical server;    -   S6.2: after receiving the message MES₁ ^(x), the medical server        verifies legality of the timestamp T₈ and the validation        parameters in the message MES₁ ^(x); the bidirectional        authentication is terminated when the timestamp T₈ and the        validation parameters are not legal, or authentication from the        smart card of the patient to the medical server is successful        when the timestamp T₈ and the validation parameters are legal;    -   S6.3: after the authentication from the smart card of the        patient to the medical server is successful, the medical server        generates a new temporary identity TID_(i) for the patient,        downloads the electronic medical record of the patient from the        blockchain based on authorization of the electronic medical        record of the patient, then generates a current timestamp T₉ and        calculates verification parameters, and sends message MES₂ ^(x)        to the device of the doctor;    -   S6.4: the device of the doctor receives the message MES₂ ^(x)        and verifies legality of the timestamp T₉ and the validation        parameters in the message MES₂ ^(x); the bidirectional        authentication is terminated when the timestamp T₉ and the        validation parameters are not legal, or authentication from the        medical server to the device of the doctor is successful when        the timestamp T₉ and the validation parameters are legal;    -   S6.5: after the authentication from the medical server to the        device of the doctor is successful, the device of the doctor        generates a current timestamp T₁₀, a session key SK_(tx) used        for communicating with the medical server and a session key        SK_(it) used for communicating with the patient, calculates        validation parameters, and sends a message MES₃ ^(x) to the        medical server;    -   S6.6: after receiving the message MES₃ ^(x), the medical server        verifies legality of the timestamp T₁₀ and the validation        parameters in the message MES₃ ^(x); the bidirectional        authentication is terminated when the timestamp T₁₀ and the        validation parameters are not legal, or authentication from the        device of the doctor to the medical server is successful when        the timestamp T₁₀ and the validation parameters are legal;    -   S6.7: after the authentication from the device of the doctor to        the medical server is successful, the medical server generates a        current timestamp T₁₁, the session key SK_(tx), used for        communicating with the doctor and a session key SK_(ix), used        for communicating with the patient, calculates verification        parameters, and sends a message MES₄ ^(x)to the user device of        the patient;    -   S6.8: after receiving the message MES₄ ^(x), the user device of        the patient verifies legality of the timestamp T₁₁ and the        validation parameters in the message MES₄ ^(x); the        bidirectional authentication is terminated when the timestamp        T₁₁ and the validation parameters are not legal, or the user        device calculates and verifies the session key SK_(it) used for        communicating with the doctor and the session key SK_(ix), used        for communicating with the medical server, when the timestamp        T₁₁ and the validation parameters are legal; and the smart card        and the user device of the patient, the medical server and the        device of the doctor successfully negotiate the session keys        with each other when verification of the session key SK_(it) and        the session key SK_(ix), is successful;    -   S6.9: after the patient and the doctor communicate with each        other by using the session key SK_(it), the doctor performs a        diagnosis Dia_(n) on the patient, generates a current timestamp        T₁₄, calculates verification parameters, and sends a message        MES₅ ^(j) to the medical server;    -   S6.10: after receiving the message MES₅ ^(x), the medical server        verifies legality of the timestamp T₁₄ and the validation        parameters in the message MES₅ ^(x); the bidirectional        authentication is terminated when the timestamp T₁₄ and the        validation parameters are not legal, or a source of a diagnostic        result is reliable and verification of the medical server is        successful when the timestamp T₁₄ and the validation parameters        are legal;    -   S6.11: after the medical server verifies legality of the        diagnostic result, the medical server generates a current        timestamp T₁₅ and the electronic medical record of the patient,        calculates validation parameters, and uploads the electronic        medical record to the blockchain, and sends a message MES₆ ^(x)        , to the user device of the patient; and    -   S6.12: after receiving the message MES₆ ^(x), the user device of        the patient verifies legality of the timestamp T₁₅ and the        validation parameters in the message MES₆ ^(x); the        bidirectional authentication is terminated when the timestamp        T₁₅ and the validation parameters are not legal, or the        electronic medical record is reliable and contents of the        electronic medical record is held accountable when the timestamp        T₁₅ and the validation parameters are legal.

In an embodiment, a method for verifying timestamps is|T_(n)′−T_(n)|≤ΔT, where T_(n) is a timestamp contained in the messagesent in any one of previous steps, T_(n)′, is a current timestampobtained by the device when receiving the message, ΔT is a presetthreshold time allowed in a communication process, an authenticationprocess is terminated when a time difference exceeds the threshold timeor a next step is proceeded when the time difference is less than thethreshold time.

In an embodiment, the authentication parameters and the session keys areencrypted and calculated using an E(GF_(q)) function of an ellipticcurve selected by the medical server; the session keys SK_(in), SK_(nj),SK_(ij), SK_(it), SK_(tx) and SK_(ix) are generated by random numbersbased on a Diffie-Hellman hard problem of the elliptic curve, and therandom numbers are generated independently by communication parties andare not transmitted publicly.

In an embodiment, the message MES₁ ^(j), the message MES₂ ^(j), themessage MES₃ ^(j), the message MES₄ ^(j), the message MES₅ ^(j), themessage MES₆ ^(j), the message MES₁ ^(x), the message MES₂ ^(x), themessage MES₃ ^(x), the message MES₄ ^(x) the message MES₅ ^(x) and themessage MES₆ ^(x) are all transmitted within a common channel.

Compared with the related art, beneficial effects of the disclosure areas follows.

A use of the blockchain technology and a dynamic anonymous policy basedon a symmetric encryption to protect privacy of the patients hasachieved secure and reliable inter-hospital identity authentication ofpatients and inter-hospital access controls of electronic medicalrecords of patients. The data of the patient cannot be tampered with,the true identity of the patient cannot be stolen, and contents of themedical record cannot be decrypted without the authorization of thepatient.

The DHKC and the elliptic curve cryptography are used to encrypt andprotect the key parameters in the authentication processes. Meanwhile,the three factor authentication method is added to encrypt the sessionkey through independently generated parameters. The disclosure canresist various attacks, including the offline password guessing attacks,the session key disclosure attacks, and insider attacks, and ensure thesecurity of authentication in the medical scenes and electronic medicalrecord access controls.

BRIEF DESCRIPTION OF DRAWINGS

Accompanying drawings generally illustrate various embodiments by way ofexample rather than limitation, and are used together with thespecification and claims to illustrate the embodiments of thedisclosure. When appropriate, the same reference numerals are usedthroughout the drawings to refer to same or similar parts. Such theembodiments are illustrative and not intended as exhaustive or exclusiveembodiments of the device or the method.

FIG. 1 is a schematic diagram of a relationship among a patient, amedical server, a doctor, and a blockchain in a system.

FIG. 2 is a schematic flowchart of an inter-hospital electronic medicalrecord access authentication protocol based on a blockchain of thedisclosure.

FIG. 3A is a schematic diagram of registering the patient on the medicalserver.

FIG. 3B is a schematic diagram of registering the doctor on the medicalserver.

FIG. 4 is a schematic diagram of initialization authentication and keyverification among the patient, the medical server, and the doctor.

FIG. 5 is a schematic diagram of generating and uploading an electronicmedical record by the medical server after initiate authentication ofthe patient and a diagnosis made by the doctor.

FIG. 6 is a schematic diagram of transfer authentication, keyverification, and electronic medical record access control among thepatient, the medical server, and the doctor after transferring thepatient to another hospital.

FIG. 7 is a schematic diagram of generating and uploading an electronicmedical record by the medical server after the transfer authenticationof the patient and a diagnosis made by the doctor.

DETAILED DESCRIPTION OF EMBODIMENTS

As shown in FIG. 1 , the disclosure provides an inter-hospitalelectronic medical record access authentication protocol based on ablockchain, mainly including a patient, a medical server, and a doctor.A smart card of the patient and a device of the doctor can storemessages. The patient and the doctor first register in the medicalserver, which stores registration messages of the patient and the doctorin the smart card of the patient and the device of the doctor,respectively. Multiple hospitals jointly maintain the blockchain and usethe blockchain to achieve inter-hospital authentication and accesscontrols of electronic medical records for patients.

As shown in FIG. 2 , a system of the inter-hospital electronic medicalrecord access authentication protocol based on the a blockchain designedby the disclosure mainly includes three parties: the patient, themedical server, and the doctor; and the process is as follows.

The patient first requests initialization authentication and a diagnosisfrom a registered hospital to a medical server. After verifying a legalidentity of the patient, the medical server sends message to a targetdoctor, and the three parties (i.e., the patient, the medical server andthe target doctor) authenticate each other and negotiate session keys.After a communication between the doctor and the patient, a diagnosticreport is generated and sent to the medical server. The medical serveruploads an authentication record of the patient and an electronicmedical record generated based on the diagnostic report to theblockchain, and sends the electronic medical record to the patient.

When the patient is transferred to another hospital, the patient submitsrequests of transfer authentication and a diagnostic to the medicalserver, and the medical server retrieves the patient authenticationrecord on the blockchain based on the requests of the patient andverifies the legal identity of the patient. After the verification, theprevious electronic medical record of the patient is decrypted based onthe authorization of the electronic medical record of the patient, andthe request of the diagnostic and previous medical record are sent to atarget doctor. The patient, the medical server, and the doctorauthenticate and negotiate the session key with each other. After thecommunication between the doctor and the patient, a diagnostic report isgenerated and sent to the medical server. The medical server uploads anauthentication record of the patient and an electronic medical recordgenerated based on the diagnostic report to the blockchain, and sendsthe electronic medical record to the patient.

As shown in FIG. 3 , in the inter-hospital electronic medical recordaccess authentication protocol based on a blockchain, a process of apatient and a doctor registering on a medical server includes thefollowing steps.

S1: initializing the medical server: the medical server selects anE(GF_(q)) function of an elliptic curve and selects a base point P onthe elliptic curve; then selects a server key k_(MSj) secretly stored inthe medical server, and calculates the public key PK_(MSj) through theE(GF_(q)) function of the elliptic curve, finally exposes parameters{E(GF_(q)),P, PK_(MSj)}.

S2: a patient and a doctor submit registration requests to the medicalserver through a user device of the patient and a device of the doctor,after the medical server verifies legality of identities of the patientand the doctor, registration messages are fed back to the user device ofthe patient and the device of doctor, and the registration messages ofthe patient and the doctor are stored on a smart card of the patient andthe device of the doctor respectively.

Steps of the S2 are as follows:

-   -   S2.1: the patient inputs an identity ID_(i), a password PW_(i)        and a biological message bio_(i) into the user device, and the        user device sends the identity ID_(i) to the medical server;    -   S2.2: after receiving and verifying legality of the identity        ID_(i) of the patient, the medical server calculates a secret        value b_(i)=h(HID_(j)∥ID_(i)∥k_(MSj)∥T_(i))between the user        device and the medical server, and sends the secret value to the        user device, then the user device calculates a biological key        (σ_(i),τ_(i))=Gen(bio_(i)), logs in to verify the parameter        HPB_(i)=h(ID_(i)∥PW_(i)∥σ_(i)), calculates        S_(p1)=h(σ_(i)∥PW_(i)∥ID_(i)) ⊕b_(i) for encrypting and storing        b_(i), and finally stores the registration message of the        patient {HPB_(i),Rep(⋅)S₁,τ_(i)T_(i)} on the smart card;

S2.3: the doctor inputs an identity DID_(n), a password PW_(n), and abiological message bio_(n) into the device of the doctor, and the deviceof the doctor sends the identity DID_(n) to the medical server through asecure channel; and

S2.4: after receiving and verifying legality of the identity DID_(n) ofthe doctor, the medical server generates a random number a_(n),calculates a public parameter A_(n)=a_(n)·P, a secret valueb_(n)=h(HID_(j)∥DID_(n)∥k_(MSj)), and an authentication parameter of thedoctor v n_(n)=h(DID_(n)∥HID_(j)∥A_(n)∥PK_(Dn))*k_(MSj)+a_(n) based onan elliptic curve point multiplication, and sends a registration message{A_(n)b_(n),a_(n)} to the device of the doctor through a secure channel.The device of the doctor verifies the registration message returned bythe medical server, and encrypts the registration message based on abiological key calculation S_(D1)=h(σ_(n)∥PW_(n)∥DID_(n))⊕b_(n),S_(D2)=h(PW_(n)∥_(n)∥DID_(n))⊕v_(n), andS_(D3)=h(PW_(n)∥DID_(n)∥⊕_(n))⊕k_(Dn). Meanwhile, a login verificationparameter HPB_(n)=h(DID_(n)∥PW_(n)∥σ_(n)) is calculated, and{HPB_(n),Rep(⋅), S_(D1), S_(D2), S_(D3), A_(n), PK_(Dn),τ_(n)} is storedon the device of the doctor.

As shown in FIG. 4 , in the inter-hospital electronic medical recordaccess authentication method based on a blockchain, the initializationauthentication and a key verification process among the patient, themedical server, and the doctor includes following steps.

S4.1: The patient inserts the smart card into the user device, andinputs an identity ID_(i)′, a password PW_(i)′, a biological messagebio_(i)′, and the user device calculates a biological keyσ_(i)′=Rep(bio_(i)′τ_(i)), and logins a verification parameterHPB_(i)′=h(ID_(i)′∥PW_(i)′∥σ_(i)′), when HPB_(i)′ and HPB_(i) stored insmart cards are not equal, a login is failed; when HPB_(i)′ is equal toHPB_(i), the login is successful.

After the patient successfully logs in, the user device of the patientgenerates a random number c_(i), a current timestamp T₁ and a diagnosticrequest Req, calculates C_(i)=c_(i)·P through the E (GF_(q)) function ofthe elliptic curve, and recovers a secret valuesb_(i)=S_(p1)⊕h(σ_(i)′∥PW_(i)′∥ID_(i)′) between the medical server andthe patient from the registration message, and calculatess_(ij)=h(c_(i)·PK_(MSj)) to encrypt authentication contents. Anencrypted message is M₁=E_(s) _(ij) (ID_(i)′,Req,T_(i),T₁), averification parameter is M₂−h(ID_(i)′∥Req∥M₁∥C_(i)∥b_(i)T₁). Finally,the user device sends a message MES₁ ^(j):{M₁,M₂,C_(i),T₁} to themedical server.

S4.2: after receiving the message MES₁ ^(j), the medical servergenerates a current timestamp T₁′, makes a judgment based on|T₁′−T₁|≤ΔT. When |T₁′−T₁|≤ΔT is not established, the medical serverterminates the authentication process; and when |T₁′−T₁|≤ΔT is true, themedical server calculates a key s_(ij)′=h(k_(Msj)·C_(i)), and recovers(ID_(i)′,Req,T_(i),T₁′)=D_(s) _(ij) ′(MO (M₁) from M₁, calculatesb_(i)′;=h(HID_(j)∥ID_(i)′∥k_(MSj)∥T_(i)) and a comparative verificationmessage M₂′=h(ID_(i)′∥Req∥M₁∥C_(i)∥b_(i)′∥T₁′); the initializationauthentication is terminated, when M₂′ is not equal to M₂ in the messageMES₁; or authentication from the smart card of the patient to themedical server is successful, when M₂′ is not equal to M₂ in the messageMES₁.

S4.3: after authentication from the smart card of the patient to themedical server is successful, the medical server generates a randomnumber e_(j) and a current timestamp T₂, and calculates E_(j)=e_(j)·P,temporary identity of the patient TID_(i)=E_(k) _(MSj) (ID_(i)′,T₂). Themedical server selects doctors DID_(n), calculates a shared secret valueb_(n)=h(HID_(j)∥DID_(n)∥k_(MSj)) with the doctor, encrypts atransmission content M₃=E_(b) _(n) (TID_(i),Req,T₂), calculates avalidation parameter M₄=h(TID₁∥DID_(n)∥Req∥C_(i)∥E_(j)∥T₂), and sends amessage MES₂ ^(j):{C_(i),E_(j),M₃,M₄,T₂} to the device of the doctor.

S4.4: the device of the doctor receives the message MES₂ ^(j), decryptsM₃: (TID_(i),Req,T₂′)=D_(b) _(n) ′(M₃), verifies legality of a timestampT₂′ and a validation parameterM₄′=h(TID_(i)∥DID_(n)′∥Req∥C_(i)∥E_(j)∥T₂′) in the message MES₂ ^(j),the initialization authentication is terminated, when the timestamp T₂′and the validation parameter M₄′ are not legal; or authentication fromthe medical server to the device of the doctor is successful, when thetimestamp T₂′ and the validation parameter M₄′ are legal.

S4.5: after authentication from the medical server to the device of thedoctor is successful, the device of the doctor generates a currenttimestamp T₃, a random number f_(n), calculates F_(n)=f_(n)·P, a sessionkey SK_(nj)=h(HID_(j)∥DID_(n)′∥b_(n)′∥b_(n)′∥f_(n)·E_(j))forcommunicating with the medical server and a session keySK_(in)=h(TID_(i)∥DID_(n)′∥f_(n)·C_(i)) used for communicating with thepatient, calculates validation parametersM₅=h(b_(n)′∥DID_(n)′∥SK_(nj)∥F_(n)∥E_(j)∥T₃) andM₆=h(TID_(i)∥DID_(n)′∥SK_(in)∥F_(n)∥C_(i)∥T₃), and sends a message MES₃^(j):{E_(j),F_(n),M₅,M₆,T₃} to the medical server.

S4.6: after receiving the message MES₃ ^(j), the medical server verifieslegality of the timestamp T₃ and the validation parameters in themessage MES₃ ^(j), the initialization authentication is terminated, whenthe timestamp T₃ and the validation parameters are not legal; orauthentication from the device of the doctor to the medical server issuccessful, when the timestamp T₃ and the validation parameters arelegal.

S4.7: after from the device of the doctor to the medical server issuccessful, the medical server generates a current timestamp T₄, asession key SK_(nj)′=h(HID_(j)∥DID_(n)∥b_(n)∥e_(j)·F_(n)) used forcommunicating with the doctor and a session keySK_(ij)=h(ID_(i)′∥HID_(j)∥s_(ij)′∥e_(j)·C_(i)) used for communicatingwith the patient, calculates a verification parameterM₅′=h(b_(n)∥DID_(n)∥SK_(nj)′∥F_(n)∥E_(j)∥T₃), the initializationauthentication is terminated, when M₅′ is not equal to M₅; or themedical server calculates encrypted a message M₇=E_(SK) _(ij)(DID_(n),TID_(i), T₃, T₄), authorization key s_(Dia1)=h(SK_(ij)′∥T₄) anda verification parameterM₈=h(TID_(i)∥DID_(n)∥s_(ij)′∥SK_(ij)∥E_(j)∥s_(Dia1)∥T₄) , when M₅′ isequal to M₅; and sends a message MES₄ ^(j):{E_(j),F_(n),M₆,M₇,M₈,T₄} tothe user device of the patient, then the medical server generates randomnumbers g_(j), and calculates G_(j)=g_(j)·P.

S4.8: after receiving the message MES₄ ^(j), the user device of thepatient verifies legality of the timestamp T₄ and the validationparameters in the message MES₄ ^(j); the initialization authenticationis terminated, when the timestamp T₄ and the validation parameters arenot legal; or the user device calculates a the session keySK_(ij)′=h(TID_(i)∥DID_(n)∥c_(i)·F_(n)) used for communicating with themedical server, decrypts M₇ to obtain (DID_(n),TID_(i),T₃′,T₄′)=D_(SK)_(ij) ′(M₇) and calculates a session keySK_(in)′=h(ID_(i)′∥HID_(j)∥s_(ij)∥c_(i)·E_(j)) used for communicatingwith the doctor, a verification parameterM₆′=h(TID_(i)∥DID_(n)∥SK_(in)′∥F_(n)∥C_(i)∥T₃′), authorization keys_(Dia1)′=h(Sk_(ij)′∥T₄), a verification parameterM₈′=h(TID_(i)∥DID_(n)∥s_(ij)∥SK_(ij)′∥E_(j)∥s_(Dia1)∥T₄), when thetimestamp T₄ and the validation parameters are legal. When M₆′ and M₈′pass the verification, the patient, the medical server, and the doctorsuccessfully negotiate the session key with each other.

As shown in FIG. 5 , after the patient initiates the authentication andthe doctor makes the diagnosis, the medical server generates and uploadsthe electronic medical record, steps are as follows.

S4.9: after the patient and the doctor communicate using the session keySK_(in), the doctor performs a diagnosis Dia_(n) on the patient,generates a current timestamp T₆, and a random number r_(n), andcalculates R_(n)=r_(n)·P, a verification parametery_(n)=v_(n)′+k′+h(DID_(n)∥Dia_(n)∥TID_(i)∥R_(n)∥T₆) * r_(n), anencrypted message M₉=E_(SK) _(nj) (TID_(i),Dia_(n),A_(n),R_(n),PK_(Dn),y_(n), T₆), and sends a message MES₅ ^(j):{DID_(n),M₉,T₆} to the medicalserver.

S4.10: after receiving the message MES₅ ^(j), the medical serververifies legality of the timestamp T₆ and the validation parameters inthe message MES₅ ^(j), the initialization authentication is terminated,when the timestamp T₆ and the validation parameters are not legal; orthe medical server decrypts(TID_(i),Dia_(n),A_(n),R_(n),PK_(Dn),y_(n),T₆′)=D_(SK) _(nj) ′(M₉), whenthe timestamp T₆ and the validation parameters are legal, and thenverifies whether y_(n)·P is equal toh(DID_(n)∥HID_(j)∥A_(n)∥PK_(Dn))·PK_(MSj)+A_(n)+PK_(Dn)+h(DID_(n)∥Dia_(n)∥TID_(i)∥R_(n)∥T₆′)·R_(n),the initialization authentication is terminated, when y_(n)·P is notequal toh(DID_(n)∥HID_(j)∥A_(n)∥PK_(Dn))·PK_(MSj)+A_(n)+PK_(Dn)+h(DID_(n)∥Dia_(n)∥TID_(i)∥R_(n)∥T₆′)·R_(n),or a source of a diagnostic result is reliable, when y_(n)·P is notequal toh(DID_(n)∥HID_(j)∥A_(n)∥PK_(Dn))·PK_(MSj)+A_(n)+PK_(Dn)+h(DID_(n)∥Dia_(n)∥TID_(i)∥R_(n)∥T₆′)·R_(n).

S4.11: after the medical server verifies legality of the diagnosisresult, the medical server generates a current timestamp T₇ and theelectronic medical record of the patient, calculates a validationparameterl_(j)=k_(MSj)+h(ID_(i)′∥DID_(n)∥TID_(i)∥HID_(j)∥s_(Dia1)∥Dia_(n)∥y_(n)∥T₇)*g_(j) and an encrypted message MR_(i1)=E_(S) _(Dia1)(DID_(n),Dia_(n),A_(n),R_(n)PK_(Dn),y_(n)l_(j),T₆), uploads theelectronic medical record {TID_(i),HID_(j),MR_(i1),G_(j),T₇} to theblockchain, and sends a message MES₆ ^(j):{HID_(j),MR_(i1),T₇} to theuser device of the patient.

S4.12: after receiving the message MES₆ ^(j), the user device of thepatient verifies legality of the timestamp T₇ and the validationparameters in the message MES₆ ^(j), the initialization authenticationis terminated, when the timestamp T₇ and the validation parameters arenot legal; or the user device of the patient decrypts(DID_(n),Dia_(n),A_(n),R_(n),PK_(Dn),y_(n),l_(j),T₆)=D_(s) _(Dia1)′(MR_(i1)), when the timestamp T₇ and the validation parameters arelegal, and the user device of the patient verifies whether l_(j)·P isequal toPK_(MSj)+h(ID_(i)′∥DID_(n)∥TID_(i)∥HID_(j)∥s_(Dia1)′∥Dia_(n)∥y_(n)∥T₇)·G_(j),the initialization authentication is terminated, when l_(j)·P is notequal toPK_(MSj)+h(ID_(i)′∥DID_(n)∥TID_(i)∥HID_(j)∥s_(Dia1)′∥Dia_(n)∥y_(n)∥T₇)·G_(j),the electronic medical record is reliable, contents of the electronicmedical record is held accountable, when l_(j)·P is equal toPK_(MSj)+h(ID_(i)′∥DID_(n)∥TID_(i)∥HID_(j)∥s_(Dia1)′∥Dia_(n)∥y_(n)∥T₇)·G_(j),and the patient encrypts and saves an authorization keyS_(p2)=h(PW_(i)′∥σ_(i)′∥ID_(i)′)⊕s_(Dia1)′ and a temporary identityTID_(i).

As shown in FIG. 6 , in the inter-hospital electronic medical recordaccess authentication protocol based on a blockchain, processes oftransfer authentication and key verification among the patient, amedical server and a doctor after the patient transferring to anotherhospital include the following steps.

S6.1: the patient inserts the smart card into the user device, inputs anidentity ID_(i)′, a password PW_(i)′, and a biological messagebio_(i)′meanwhile, the user device calculates biological keys⊕_(i)′=Rep(bio_(i)′,τ_(i)) and logins a verification parameterHPB_(i)′=h(ID_(i)′∥PW_(i)′∥σ_(i)′), when HPB_(i)′ is not equal to theHPB_(i) stored in the smart card, a login is failed; when HPB_(i)′ isequal to the HPB_(i) stored in the smart card, the login is successful.

After the patient successfully logs in, the user device of the patientcalculates an authorization keys_(Dia1)′=S_(p2)⊕h(PW_(i)′∥σ_(i)′∥ID_(i)′), generates a random number0_(i), a current timestamp T₁ and a diagnostic request Req, calculatesO_(i)=o_(i)·P through the E(GF_(q)) function of the elliptic curve, andcalculates s_(ix)=h(o_(i)·PK_(MSx)) to encrypt authentication contents,an encrypted message is W₁=E_(s) _(ix)(TID_(i)ID_(i)′,Req*,s_(Dia1)′O_(i),T₈), and finally sends a messageMES₁ ^(x):{O_(i),W₁,T₈} to the medical server.

S6.2: after receiving the message MES₁ ^(x), the medical server verifieswhether a timestamp is valid, and the transfer authentication isterminated, when the timestamp is not valid; or the medical servercalculates a key s_(ix)′=h(k_(MSx)·O_(i)), recovers(TID_(i)′,ID_(i)′,Req*,s_(Dia1)′O_(i)′,T₈′=D_(s) _(ix) ′(W₁), when thetimestamp is valid; the transfer authentication is terminated, whenO_(i)′ is not equal to T₈′ are; or authentication from the smart card ofthe patient to the medical server is successful, when O_(i)′ is equal toT₈′.

S6.3: after the authentication from the smart card of the patient to themedical server is successful, the medical server retrieves and decryptsan electronic medical record (DID_(n), Dia_(n), A_(n), R_(n), K_(Dn),y_(n), l_(j), T₆)=D_(s) _(Dia1) ′ (MR_(i1)) based on TID_(i)′, andverifies legality of contents of the electronic medical record byverifying whether l_(j)·P is equal toPK_(MSj)+h(ID_(i)′∥DID_(n)∥TID_(i)′∥HID_(j)∥s_(Dia1)′∥Dia_(n)∥y_(n)∥T₇)·G_(j),when l_(j)·P is equal toPK_(MSj)+h(ID_(i)′∥DID_(n)∥TID_(i)′∥HID_(j)∥s_(Dia1)′∥Dia_(n)∥y_(n)∥T₇)·G_(j),the medical server generates a random number q_(x) and the currenttimestamp T₉, and calculates Q_(x)=q_(x)·P, a temporary identity of thepatient TID_(i2)=E_(k) _(MSx) (ID_(i)′, T₉). The medical server selectsa doctor DID_(t), calculates a common secret valueb_(t)=h(HID_(x)∥DID_(t)∥k_(MSx)) with the doctor, encrypts transmissioncontents W₂=E_(b) _(t) (TID_(i2), Reg*, Dia_(n),T₉), calculates averification parameter W₃=h(TID_(i2)∥DID_(t)∥Req*∥Dia_(n)∥O_(i)Q_(x)∥T₉)and sends a message MES₂ ^(x):{O_(i),Q_(x), W₂, W₃, T₉} to the device ofthe doctor.

S6.4: the device of the doctor receives the message MES₂ ^(x), decryptsW₂ (TID_(i2), Reg*, Dia_(n), T₉′)=D_(b)′(W₂), verifies legality of avalidation parametersW₃′=h(TID_(i2)∥DID_(t)∥Req*∥Dia_(n)∥O_(i)∥Q_(x)∥T₉′) in the message MES₂^(x), the transfer authentication is terminated, when the validationparameters W₃′ is not legal; or authentication from the medical serverto the device of the doctor is successful, when the validationparameters W₃′ is legal.

S6.5: after the authentication from the medical server to the device ofthe doctor is successful, the device of the doctor generates a currenttimestamp T₁₀, a random number f_(t), calculates F_(t)=f_(t)·P , asession key SK_(tx)=h(HID_(x)∥DID_(t)′∥b_(n)′∥f_(t)·Q_(x)) used forcommunicating with the medical server and a session keySK_(it)=h(TID_(i2)∥DID_(t)′∥f_(t)·O_(i)) used for communicating with thepatient, calculates validation parametersW₄=h(b_(t)′∥DID_(t)′∥SK_(tx)∥F_(t)∥Q_(x)∥T₁₀) andW₅=h(TID_(i2)∥DID_(t)′∥SK_(it)∥F_(t)∥O_(i)∥T₁₀), and sends a messageMES₃ ^(x):{Q_(x),F_(t),W₄,W₅,T₁₀} to the medical server.

S6.6: after receiving the message MES₃ ^(x), the medical server verifieslegality of the timestamp T₁₀ and the validation parameters in themessage MES₃ ²; the transfer authentication is terminated, when thetimestamp T₁₀ and the validation parameters are not legal; orauthentication from the device of the doctor to the medical server issuccessful, when the timestamp T₁₀ and the validation parameters arelegal.

S6.7: after the authentication from the device of the doctor to themedical server is successful, the medical server generates a currenttimestamp T₁₁, a session keySK_(tx)′=h(HID_(j)∥DID_(t)∥b_(n)∥q_(x)·F_(t)) used for communicatingwith the doctor and a session keySK_(ix)=h(ID_(i)′∥HID_(x)∥s_(ix)′∥q_(x)·O_(i)) used for communicatingwith the patient, calculates verification parametersW₄′=h(b_(t)∥DID_(t)∥SK_(tx)′∥F_(t)∥Q_(x)∥T₁₀); the transferauthentication is terminated, when W₄′ is not equal to W₄; otherwise themedical server calculates an encrypted message W₆=E_(SK) _(ix)(DID_(t)TID_(i2),T₁₀,T₁₁), an authorization key s_(Dia2)=h(SK_(ix)∥T₁₁),and a validation parameterW₇=h(TID_(i2)∥DID_(t)∥SK_(ix)∥F_(t)∥Q_(x)∥s_(Dia2)∥T₁₁), and sends amessage MES₄ ^(j):{Q_(x)F_(t),W₅,W₆,W₇,T₁₁} to the user device of thepatient, then the medical server generates a random number g_(x) andcalculates G_(x)=g_(x)·P.

S6.8: after receiving the message MES₄ ^(x), the user device of thepatient verifies legality of the timestamp T₁₁ and the validationparameters in the message MES₄ ^(x), the transfer authentication isterminated, when the timestamp T₁₁ and the validation parameters are notlegal; or the user device of the patient calculates the session keySK_(ix)′=h(ID_(i)′∥HID_(x)∥s_(ix)∥o_(i)·Q_(x)) used for communicatingwith the medical server, decrypts W₇ to obtain (DID_(t),TID_(i2),T₁₀′,T₁₁′)=D_(SK) _(ix) ′(W₇), calculates a session keySK_(it)′=h(TID_(i2)∥DID_(t)∥o_(i)·F_(t)) used for communicating with thedoctor, a verification parameterK₅′=h(TID_(i2)∥DID_(t)∥SK_(it)′∥F_(t)∥O_(i)∥T₁₀′), an authorization keys_(Dia2)′=h(SK_(ix)′∥T₁₁), a verification parameterW₇′=h(TID_(i2)∥DID_(t)∥SK_(ix)′∥F_(t)∥Q_(x)∥s_(Dia2)′∥T₁₁′), when thetimestamp T₁₁ and the validation parameters are legal; when W₅′ and W₇′pass the verification, the session key is successfully negotiated amongthe patient, the medical server, and the doctor.

As shown in FIG. 7 , after the transfer authentication and a diagnosismade by the doctor, the medical server generates and uploads anelectronic medical record including following steps.

S6.9: after the patient and doctor communicate using the negotiatedsession key SK_(it), the doctor performs a diagnosis Dia_(t) on thepatient, generates a current timestamp T₁₄ and a random number r_(t),calculates R_(t)=r_(t)·P, a verification parametery_(t)=v_(t)′+k_(Dt)+h(DID_(t)∥Dia_(t)∥TID_(i2)∥R_(t)∥T₁₄) *r_(t) and anencrypted message W₉=E_(SK) _(tx) (TID_(i2), Dia_(t), A_(t), R_(t),PK_(Dt), Y_(t),T₁₄), and sends a message MES₅ ^(x):{DID_(t),W₉,T₁₄} tothe medical server.

S6.10: after receiving the message MES₅ ^(x), the medical serververifies legality of the timestamp T₁₄ and the validation parameters inthe message MES₅ ^(x); the transfer authentication is terminated, whenthe timestamp T₁₄ and the validation parameters are not legal; or themedical server decrypts(TID_(i2),Dia_(t),A_(t),R_(t),PK_(Dt),y_(t),T₁₄′=D_(SK) _(tx) ′(W₉),when the timestamp T₁₄ and the validation parameters are legal; and themedical server verifies whether y_(t)·P is equal toh(DID_(t)∥HID_(x)∥A_(t)∥PK_(Dt))·PK_(MSx)+A_(t)+PK Dt+h(DID_(t)∥Dia_(t)∥TID_(i2)∥R_(t)∥T₄′)·F_(t), the transferauthentication is terminated, when y_(t)·P is not equal toh(DID_(t)∥HID_(x)∥A_(t)∥PK_(Dt))·PK_(MSx)+A_(t)+PK_(Dt)+h(DID_(t)Dia_(t)∥TID_(i2)∥R_(t)∥T₁₄′)·F_(t);or a source of a diagnostic result is reliable, when y_(t) ·P is notequal toh(DID_(t)∥HID_(x)∥A_(t)∥PK_(Dt))·PK_(MSx)+A_(t)+PK_(Dt)+h(DID_(t)∥Dia_(t)∥TID_(i2)∥R_(t)∥T₁₄′)·F_(t).

S6.11: after the medical server verifies legality of the diagnosticresult, the medical server generates a current timestamp T₁₅ and theelectronic medical record of the patient, calculates a validationparameterl_(x)=k_(MSx)+h(ID_(i)′∥DID_(t)∥TID_(i2)∥HID_(x)∥s_(Dia2)∥Dia_(t)∥Y_(t)∥T₁₅) *g_(x) and an encrypted message MR_(i2)E_(s) _(Dia2)(DID_(t),Dia_(t),A_(t),R_(t),PK_(Dt),y_(t),l_(x), T₁₅, TID_(i), Dia_(n),s_(Dia1)), uploads the electronic medical record{TID_(i2),HID_(x),MR_(i2),G_(x),T₁₅} to the blockchain, and sends amessage MES₆ ^(x):{HID_(x),MR_(i2), T₁₅} to the user device of thepatient.

S6.12: after receiving the message MES₆ ^(x), the user device of thepatient verifies the legality of the timestamp T₁₅ and the validationparameters in the message MES₆ ^(x); the transfer authentication isterminated, when the timestamp T₁₅ and the validation parameters are notlegal; or the user device of the patient decrypts (DID_(t), Dia_(t),A_(t), R_(t), PK_(Dt),y_(t),l_(x)T₁₅, TID_(i), Dia_(n), s_(Dia1))=D_(s)_(Dia2) ′(MR_(i2)), when the timestamp T₁₅ and the validation parametersare legal; and the user device of the patient verifies whether l_(x)·Pis equal toPK_(MSx)+h(ID_(i)′∥DID_(t)∥TID_(i2)∥HID_(x)∥S_(Dia2)∥Dia_(t)∥y_(t)∥T₁₅)·G_(x);the transfer authentication is terminated, when l_(x)·P is not equal toPK_(MSx)+h(ID_(i)′∥DID_(t)∥TID_(i2)∥HID_(x)∥s_(Dia2)∥Dia_(t)∥y_(t)∥T₁₅)·G_(x);or the electronic medical record is reliable and contents of theelectronic medical record is held accountable, when l_(x)·P is equal toPK_(MSx)h(ID_(i)′∥DID_(t)∥TID_(i2)∥HID_(x)∥s_(Dia2)∥Dia_(t)∥Y_(t)∥T₁₅)·G_(x);and then the patient encrypts and saves an authorization keyS_(p2)=h(PW_(i)′∥σ_(i)′∥ID_(i)′)⊕s_(Dia2)′ and a temporary identityTID_(i2).

The above-described embodiments are only a description of theillustrated method of the disclosure, not a limitation of the scope ofthe disclosure. Without departing from the spirit of the design of thedisclosure, various modifications and changes made by those skilled inthe art to the technical solution of the disclosure shall fall withinthe scope of protection determined by the claims of the disclosure.

What is claimed is:
 1. An inter-hospital electronic medical recordaccess authentication method based on a blockchain, comprising thefollowing steps: S1: initializing a medical server; S2: submitting, by auser device of a patient and a device of a doctor, registration requeststo the medical server; feeding, by the medical server, registrationmessages back to the user device of the patient and the device of thedoctor after verifying legality of the patient and the doctor; andstoring the registration messages of the patient and the doctor on asmart card of the patient and the device of the doctor respectively; S3:submitting, by the user device of the patient, an initializeauthentication request to the medical server; S4: performing, by thedoctor, a diagnosis on the patient after completing initializeauthentication among the patient, the medical server and the doctor fornegotiating session keys for communications; and uploading, by themedical server, an electronic medical record of the patient to theblockchain; S5: submitting, by the patient, a transfer authenticationrequest to another medical server of another hospital where the patientis located when the patient is transferred to the another hospital; andS6: authorizing, by the patient, the another medical server to accessthe electronic medical record of the patient after completing transferauthentication among the patient, the another medical server, andanother doctor in the another hospital for negotiating and verifyingsession keys for communications; performing, by the another doctor, adiagnosis on the patient; and uploading, by the another medical server,another electronic medical record of the patient to the blockchain. 2.The inter-hospital electronic medical record access authenticationmethod based on the blockchain as claimed in claim 1, wherein theinitializing a medical server in the S1 comprises: selecting, by themedical server, an E(GF_(q)) function of an elliptic curve; selecting abase point P on the elliptic curve; then selecting a server key k_(MSj)and storing the server key k_(MSj) in the medical server; andcalculating, by the medical server, a public key PK_(MSj) through theE(GF_(q)) function of the elliptic curve, and exposing parameters{E(GF_(q)), P, PK_(MSj)}.
 3. The inter-hospital electronic medicalrecord access authentication method based on the blockchain as claimedin claim 1, wherein the S2 comprises: S2.1: inputting, by the patient,an identity ID_(i), a password PW_(i) and a biological message bio_(i)into the user device of the patient; and sending, by the user device ofthe patient, the identity ID_(i) to the medical server through a securechannel; S2.2: calculating, by the medical server, a secret value b_(i)between the patient and the medical server after receiving and verifyinglegality of the identity ID_(i) of the patient; and sending, by themedical server, the registration message of the patient to the userdevice of the patient through a secure channel for the storing; S2.3:inputting, by the doctor, an identity DID_(n), a password PW_(n), and abiological message bio_(n) into the device of the doctor, and sending,by the device of the doctor, the identity DID_(n) to the medical serverthrough a secure channel; and S2.4: calculating, by the medical server,a secret value b_(n) between the doctor and the medical server afterreceiving and verifying legality of the identity DID_(n) of the doctor;and sending, by the medical server, the registration message of thedoctor to the device of the doctor through a secure channel for thestoring.
 4. The inter-hospital electronic medical record accessauthentication method based on the blockchain as claimed in claim 1,wherein the initialize authentication in the S4 is based onbidirectional authentication and key negotiation and verification amongthe smart card and the user device of the patient, the medical serverand the device of the doctor; and uploading the electronic medicalrecord of the patient in the S4 is based on a mutual confirmation amongthe smart card and the user device of the patient, the medical serverand the device of the doctor, and the electronic medical record isuploaded to the blockchain by the medical server.
 5. The inter-hospitalelectronic medical record access authentication method based on theblockchain as claimed in claim 4, wherein the S4 comprises: S4.1:inserting, by the patient, the smart card into the user device; andgenerating, by the user device, a current timestamp T₁ through theregistration message in the smart card after passing identityauthentication; calculating, by the user device, verificationparameters; and sending, by the user device, a message ME₁ ^(j) to themedical server; S4.2: verifying, by the medical server, legality of thetimestamp T₁ and the validation parameters in the message MES₁ ^(j)after receiving the message MES₁ ^(j); wherein the bidirectionalauthentication is terminated when the timestamp T₁ and the validationparameters are not legal, or an authentication from the smart card ofthe patient to the medical server is successful when the timestamp T₁and the validation parameters are legal; S4.3: generating, by themedical server, a temporary identity TID_(i) of the patient and acurrent timestamp T₂ after the authentication from the smart card of thepatient to the medical server is successful; calculating, by the medicalserver, verification parameters; and sending, by the medical server, amessage MES₂ ^(j) to the device of the doctor; S4.4: receiving, by thedevice of the doctor, the message MES₂ ^(j); and verifying legality ofthe timestamp T₂ and the validation parameters in the message MES₂ ^(j);wherein the bidirectional authentication is terminated when thetimestamp T₂ and the validation parameters are not legal, or anauthentication from the medical server to the device of the doctor issuccessful when the timestamp T₂ and the validation parameters arelegal; S4.5: generating, by the device of the doctor, a currenttimestamp T₃, a session key SK_(nj) used for communicating with themedical server and a session key SK_(in) used for communicating with thepatient after the authentication from the medical server to the deviceof the doctor is successful; calculating, by the device of the doctor,validation parameters; and sending, by the device of the doctor, amessage MES₃ ^(j) to the medical server; S4.6: verifying, by the medicalserver, legality of the timestamp T₃ and the validation parameters inthe message MES₃ ^(j) after receiving the message MES₃ ^(j); wherein thebidirectional authentication is terminated when the timestamp T₃ and thevalidation parameters are not legal, or an authentication from thedevice of the doctor to the medical server is successful when thetimestamp T₃ and the validation parameters are legal; S4.7: generating,by the medical server, a current timestamp T₄, a session key SK_(nj)′used for communicating with the doctor and a session key SK_(ij) usedfor communicating with the patient after the authentication from thedevice of the doctor to the medical server is successful; calculating,by the medical server, validation parameters; and sending, by themedical server, a message MES₄ ^(j) to the user device of the patient;S4.8: verifying, by the user device, legality of the timestamp T₄ andthe validation parameters in the message MES₄ ^(j) after receiving themessage MES₄ ^(j); wherein the bidirectional authentication isterminated when the timestamp T₄ and the validation parameters are notlegal, or the user device calculates and verifies a session key SK_(in)′used for communicating with the doctor and a session key SK_(ij)′ usedfor communicating with the medical server when the timestamp T₄ and thevalidation parameters are legal; and the smart card and the user deviceof the patient, the medical server and the device of the doctorsuccessfully negotiate the session keys with each other when theverification of the session key SK_(in)′ and the session key SK_(ij)′ issuccessful; S4.9: performing, by the doctor, a diagnosis Dia_(n) on thepatient after the patient and the doctor communicating by using thesession key SK_(in); generating, by the device of the doctor, a currenttimestamp T₆; calculating, by the device of the doctor, verificationparameters, and sending, by the device of the doctor, a message MES₅^(j) to the medical server; S4.10: verifying, by the medical server,legality of the timestamp T₆ and the validation parameters in themessage MES₅ ^(j) after receiving the message MES₅ ^(j); wherein thebidirectional authentication is terminated when the timestamp T₆ and thevalidation parameters are not legal, or a source of a diagnostic resultis reliable and verification of the medical server is successful whenthe timestamp T₆ and the validation parameters are legal; S4.11:generating, by the medical server, a current timestamp T₇ and theelectronic medical record of the patient after the medical serververifies legality of the diagnosis result; calculating, by the medicalserver, validation parameters; uploading, the medical server, theelectronic medical record to the blockchain; and sending, by the medicalserver, a message MES₆ ^(j) to the user device of the patient; andS4.12: verifying, by the user device of the patient, legality of thetimestamp T₇ and the validation parameters in the message MES₆ ^(j)after receiving the message MES₆ ^(j); wherein the bidirectionalauthentication is terminated when the timestamp T₇ and the validationparameters are not legal, or the electronic medical record is reliableand contents of the electronic medical record is held accountable whenthe timestamp T₇ and the validation parameters are legal.
 6. Theinter-hospital electronic medical record access authentication methodbased on a blockchain as claimed in claim 1, wherein the transferauthentication in the S6 is based on bidirectional authentication andkey negotiation and verification among the smart card and the userdevice of the patient, the another medical server and a device of theanother doctor; and uploading the another electronic medical record inthe S6 is based on mutual confirmation among the smart card and the userdevice of the patient, the another medical server and the device of theanother doctor, and the another electronic medical record is uploaded tothe blockchain by the another medical server.
 7. The inter-hospitalelectronic medical record access authentication method based on ablockchain as claimed in claim 6, wherein the S6 comprises: S6.1:inserting, by the patient, the smart card into the user device; andgenerating, by the user device, a current timestamp T₈ through theregistration message in the smart card after passing identityauthentication; calculating, by the user device, verificationparameters; and sending, by the user device, a message MES₁ ^(x) to themedical server; S6.2: verifying, by the medical server, legality of thetimestamp T₈ and the validation parameters in the message MES₁ ^(x)after receiving the message MES₁ ^(x); wherein the bidirectionalauthentication is terminated when the timestamp T₈ and the validationparameters are not legal, or an authentication from the smart card ofthe patient to the medical server is successful when the timestamp T₈and the validation parameters are legal; S6.3: generating, by themedical server, a temporary identity TID_(i) of the patient after theauthentication from the smart card of the patient to the medical serveris successful; downloading, by the medical server, the electronicmedical record of the patient from the blockchain based on authorizationof the electronic medical record of the patient; generating, by themedical server, a current timestamp T₉; calculating, by the medicalserver, verification parameters; and sending, by the medical server, amessage MES₂ ^(x) to the device of the doctor; S6.4: receiving, by thedevice of the doctor, the message MES₂ ^(x); and verifying legality ofthe timestamp T₉ and the validation parameters in the message MES₂ ^(x);wherein the bidirectional authentication is terminated when thetimestamp T₉ and the validation parameters are not legal, or anauthentication from the medical server to the device of the doctor issuccessful when the timestamp T₉ and the validation parameters arelegal; S6.5: generating, by the device of the doctor, a currenttimestamp T₁₀, a session key SK_(tx), used for communicating with themedical server and a session key SK_(it) used for communicating with thepatient after the authentication from the medical server to the deviceof the doctor is successful; calculating, by the device of the doctor,validation parameters; and sending, by the device of the doctor, amessage MES₃ ^(x) to the medical server; S6.6: verifying, by the medicalserver, legality of the timestamp T₁₀ and the validation parameters inthe message MES₃ ^(x) after receiving the message MES₃ ^(x); wherein thebidirectional authentication is terminated when the timestamp T₁₀ andthe validation parameters are not legal, or an authentication from thedevice of the doctor to the medical server is successful when thetimestamp T₁₀ and the validation parameters are legal; S6.7: generating,by the medical server, a current timestamp T₁₁, a session key SK_(tx)′used for communicating with the doctor and a session key SK_(ix) usedfor communicating with the patient after the authentication from thedevice of the doctor to the medical server is successful; calculating,by the medical server, validation parameters; and sending, by themedical server, a message MES₄ ^(x) to the user device of the patient;S6.8: verifying, by the user device, legality of the timestamp T₁₁ andthe validation parameters in the message MES₄ ^(x) after receiving themessage MES₄ ^(x); wherein the bidirectional authentication isterminated when the timestamp T₁₁ and the validation parameters are notlegal, or the user device calculates and verifies a session key SK_(it)′used for communicating with the doctor and a session key SK_(ix)′ usedfor communicating with the medical server when the timestamp T₁₁ and thevalidation parameters are legal; and the smart card and the user deviceof the patient, the medical server and the device of the doctorsuccessfully negotiate the session keys with each other when theverification of the session key SK_(it)′ and the session key SK_(ix)′ issuccessful; S6.9: performing, by the doctor, a diagnosis Dia_(t) on thepatient after the patient and the doctor communicating by using thesession key SK_(it); generating, by the device of the doctor, a currenttimestamp T₁₄; calculating, by the device of the doctor, verificationparameters, and sending, by the device of the doctor, a message MES₅^(x) to the medical server; S6.10: verifying, by the medical server,legality of the timestamp T₁₄ and the validation parameters in themessage MES₅ ^(x) after receiving the message MES₅ ^(x); wherein thebidirectional authentication is terminated when the timestamp T₁₄ andthe validation parameters are not legal, or a source of a diagnosticresult is reliable and verification of the medical server is successfulwhen the timestamp T₁₄ and the validation parameters are legal; S6.11:generating, by the medical server, a current timestamp T₁₅ and theelectronic medical record of the patient after the medical serververifies the legality of the diagnostic result; calculating, by themedical server, validation parameters; uploading, the medical server,the electronic medical record to the blockchain; and sending, by themedical server, a message MES₆ ^(x) to the user device of the patient;and S6.12: verifying, by the user device of the patient, legality of thetimestamp T₁₅ and the validation parameters in the message MES₆ ^(x)after receiving the message MES₆ ^(x); wherein the bidirectionalauthentication is terminated when the timestamp T₁₅ and the validationparameters are not legal, or the electronic medical record is reliableand contents of the electronic medical record is held accountable whenthe timestamp T₁₅ and the validation parameters are legal.
 8. Theinter-hospital electronic medical record access authentication methodbased on a blockchain as claimed in claim 5, wherein a method forverifying timestamps is |t_(n)′−T_(n)|≤ΔT;T_(n) is a timestamp containedin a message, T_(n)′ is a current timestamp obtained by a device whenreceiving the message, ΔT is a preset threshold time allowed in acommunication process; an authentication process is terminated when atime difference exceeds the preset threshold time, or a next step isproceeded when the time difference is less than the preset thresholdtime.
 9. The inter-hospital electronic medical record accessauthentication method based on a blockchain as claimed in claim 5,wherein the authentication parameters and the session keys are encryptedand calculated using an E(GF_(q)) function of an elliptic curve selectedby the medical server; the session keys SK_(in),SK_(nj), and SK_(ij) aregenerated by random numbers based on a Diffie-Hellman hard problem ofthe elliptic curve, and the random numbers are generated independentlyby communication parties and are not transmitted publicly.
 10. Theinter-hospital electronic medical record access authentication methodbased on a blockchain as claimed in claim 5, wherein the message MES₁^(j), the message MES₂ ^(j), the message MES₃ ^(j), the message MES₄^(j), the message MES₅ ^(j), and the message MES₆ ^(j) are alltransmitted within a common channel.